home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
822ext
/
822ext-minutes-93mar.txt
< prev
next >
Wrap
Text File
|
1993-05-10
|
6KB
|
130 lines
CURRENT_MEETING_REPORT_
Reported by Greg Vaudreuil/CNRI
Minutes of the Internet Message Extensions Working Group (822EXT)
The Internet Message Extensions Working Group met twice in Columbus to
review and approve the MIME protocol for submission as a Draft Standard.
With a handful of changes, the MIME protocol was approved. The Working
Group agreed to disband after publication of the revised document.
Several new working groups will be formed to define extensions to the
MIME protocol and additional content-types.
The solutions listed in the latest MIME issues list, as distributed
periodically to the IETF-822 mailing list, were accepted with the
following additions and changes:
o Encoding of Content-Type Message
RFC1421 prohibits the use of a content-transfer-encoding other than
7bit, 8bit, and Binary on the message type. This was designed to
ensure that both the structure of a MIME message is visible without
decoding and that nested encodings were not generated.
Implementation experience has uncovered several problems with the
use of message/partial and message/external-body when conversion is
required in a gateway. In particular, using a non-null of a
partial 8 bit message for 7 bit transport is prohibited. Even if
it was allowed, re-encoding the message into a 7 bit encoding would
be likely to cause message size growth, defeating the intent of
using message partial in the first case.
The question for the Group was whether to limit encoding of any
message type to 7 bit or only message/partial. The Group agreed to
modify the prohibition to allow only content-transfer-encoding of
7bit for the message/partial content-type.
o Representation of Filenames in Message/External-body
The inclusion of filenames in the content-type headers has the
effect of requiring that all filenames be 7 bit ASCII. The Working
Group discussed the likelihood that new operating systems will
require a richer character set for filenames and the possibility
that when this occurs the current filename mechanism may not be
adequate. After lengthy discussion during which the Group
considered the possibility of using an encoded word from RFC1342,
it was agreed that no changes should be made at this time and that
when needed a new content-type could be defined with an enhanced
mechanism.
o Definition of Charset
The Working Group agreed to significantly trim the definition of a
character set and to eliminate specific wording about specific
unregistered character sets. The discussion of specific character
1
sets not currently listed with IANA was eliminated, (see the
revised document for the new wording). Agreement was reached to
remove Appendix F.2, the procedure for IANA registration, in favor
of a statement pointing to the IANA for the procedure. It is
expected that this procedure will evolve independently of MIME.
Issues related to the application of the general principle of a
``charset'' to specific current and future character sets is not
part of the Charter of this Working Group and will be the subject
of a new working group chartered to address the character set
issues in a more general IETF context.
o MIME-Version: 1.0 Header Semantics
The Working Group discovered that the MIME-Version header was
insufficiently defined to be used for true versioning and that the
interpretation of this header was not uniform across current
implementations. Understanding that backward compatible changes to
MIME were unlikely and that changing the version in the current
header will cause at least one implementation to fail to recognize
the message as valid MIME, the Working Group agreed that this
header should now be considered a string constant; any version
specific notes should be encoded as an RFC822 comment in the
MIME-version header line, a feature available in all other RFC822
headers.
Attendees
Harald Alvestrand Harald.Alvestrand@delab.sintef.no
Gabe Beged-Dov gabe@cv.hp.com
Nathaniel Borenstein nsb@bellcore.com
Kevin Carosso kvc@innosoft.com
George Chang gkc@ctt.bellcore.com
William Chung whchung@watson.ibm.com
James Conklin jbc@bitnic.educom.edu
Al Costanzo al@akc.com
Urs Eppenberger eppenberger@switch.ch
Erik Fair fair@apple.com
Roger Fajman raf@cu.nih.gov
Ned Freed ned@innosoft.com
James Galvin galvin@tis.com
Christine Garland garland@ihspa.att.com
Terry Gray gray@cac.washington.edu
Alton Hoover hoover@ans.net
Jeroen Houttuin houttuin@rare.nl
Marko Kaittola Marko.Kaittola@funet.fi
Neil Katin katin@eng.sun.com
John Klensin klensin@infoods.unu.edu
Jim Knowles jknowles@binky.arc.nasa.gov
Mary La Roche maryl@cos.com
Keith Moore moore@cs.utk.edu
Masataka Ohta mohta@cc.titech.ac.jp
Emmanuel Pasetes ekp@enlil.premenos.sf.ca.us
2
Francois Robitaille francois.robitaille@crim.ca
Marshall Rose mrose@dbc.mtview.ca.us
Carl Schoeneberger 70410.3563@Compuserve.com
Gregory Sheehan gregory.c.sheehan@att.com
Einar Stefferud stef@nma.com
Gregory Vaudreuil gvaudre@cnri.reston.va.us
3